Note: This will be breaking ABI, but not API.

I am not sure it this is the right way. I would prefer to guide people setting this up on the teach pendant. Though they need to remember to save the installation

I am not sure it this is the right way. I would prefer to guide people setting this up on the teach pendant. Though they need to remember to save the installation

I don't quite understand why that should be the case. We offer a functionality to set an analog output and this PR merely adds the possibility to specify whether this is a current or a voltage.

Is what you are saying that users should select on the TP which domain to use and the functionality in the client library shouldn't modify the domain at all? We could also add a third state "don't change" which could be the default. One problem there would be that at least for ROS 1 the default value would be 0 which I would not like to remap to "don't change" since 0 on the low-level interface means "current".

Thinking about it, that might be the best solution: Provide a default value of -1 that will not change the domain.

We could also add a third state "don't change" which could be the default. One problem there would be that at least for ROS 1 the default value would be 0 which I would not like to remap to "don't change" since 0 on the low-level interface means "current".

Thinking about it, that might be the best solution: Provide a default value of -1 that will not change the domain.

I like the idea of giving the flexibility to do both.

I like the idea of giving the flexibility to do both.

I've updated the PR accordingly. When not passing the domain, it is not set in the RTDEWriter.